Empirical Investigations in Software Architecture Completeness

3 A. Abstract Especially in large-scale industrial software projects there is the need for applying quality assuring techniques already in early stages of the development process, i.e. the architecture and design phases. In these stages models are used to analyze and describe the software system. As the models in large-scale projects are created and used by many team members and external stakeholders it is a necessity to maximize comprehensibility. The UML is the most commonly used notation used in software engineering projects. It is a common hypothesis that the freedom allowed by the UML involves miscommunication and integration overhead and complicates the two afore mentioned needs in software projects. In large projects it is difficult to oversee the completeness of a model under development. For the MSc project described in this thesis we performed a survey through questionnaires. The survey confirmed this hypothesis. The UML is used loosely by practitioners; deadline stress and lack of conventions cause that the architecture models are incomplete and inconsistent, i.e. they lack elements and contain conflicting information between different types of diagram. This leads to uncertainty whether quality inspections are trustworthy at a given point of time, and it leads to miscommunication, integration problems and testing overhead. In this project completeness and consistency of UML models is defined. A set of rules and metrics is proposed to manage large models (with respect to completeness and consistency). To specify violations of completeness and consistency we have created a meta model of the four most commonly used diagram types. We extended an existing tool to calculate the rules and metrics automatically given an UML model. In six large-scale case studies these rules and metrics are validated. Besides validation of the rules and metrics the case studies serve to investigate violations of completeness and consistency in UML models. We make the following observations: ÷! The absolute number of completeness and consistency violations is quite large. In industrial practice, the designs are moved to the next stage with still a significant number of violations. ÷! The types of violations occurring in a model are related to the architect’s habits, education and other factors. ÷! A heuristic is presented that indicates the internal dynamic behavior of a class. The presented dynamicity is useful for the identification of highly dynamic classes. Interestingly the dynamicity histogram shows similar characteristics for all cases. ÷! The two case studies performed as a post-graduate student project have the best score. This probably due to the fact that the time pressure for such a small project is less than in industrial settings and that the students learned UML modeling at the university and not on the job, like most industrial architects. ÷! The presented rules and metrics cannot ultimately identify violations, but point the architect to the suspects. The architect has to judge whether it is a violation. The techniques help finding violations efficiently and encourage model improvements. In practice most suspects turned out to be guilty.